SD-FI - Surya - Deepak - Siba - Raghav - 2016-01-18 - 24193 - Service Request - 2016 Order Fulfillment and HR - Week ending April 16 (Jeffrey Mau by 2016-12-31) #SDSupportOrderEntry
2016-01-18 - 24193 - Service Request - 2016 Order Fulfillment and HR
Problem Summary
All supporting activities that are less than 4 hours in 2016 are updated in this sheet.
Admin Info
| Purpose |
All supporting activities that are less than 4 hours in 2016 are updated in this sheet. |
| Requested by |
Jeffrey Mau |
| Issue Date |
04/11/2016 - 04/16/2016 |
| Resolved by |
Surya/Deepak/Siba/Raghav |
| Resolved Date |
04/16/2016 |
| Document Status |
Resolved |
Detailed Problem Description
(Include Screen Shots if required )01. 04/11/2016 - NEC reported that Delivery # 83206141 was not able to pack. And an error message was showing up in the output "Multiple VAS codes found can't be packed".
02. Continuation of analysis for the same issue as on dated 03/23/2016 - As per our earlier solution provided during the retail implementation in Japan and korea for ZRSD condition type in the pricing procedure. We made some changes by altering the calculation routine for NETP and PNTP condition type. So this time business wants to apply the same for retail pricing (US & Canada). So we need to find out each calculation routine (17 & 3) does, and provide the analysis of possible impacts of this change. - (By Dan)
Solution Analysis and Recommendations
(Include Screen Shots if required)01. 04/11/2016 - Below is the screen shot of the Delivery # 83206141 with multiple VAS codes where we found multiple VAS codes has been maintained. (By Dan)
According the current packing program, while packing the delivery system is checking the entries available in the table ZPWEAVER_VASRL to avoid the duplicate entry and in the above NEP example VAS codes found (P01, P07 & P21). And P21 is maintained in table ZPWEAVER_VASRL, so system is considering as multiple entries and displaying the error message.
Screen shot of NEP - Table Entries in ZPWEAVER_VASRL
In NECNEDD - 300, we tried to pack the delivery document after deleting the entry of P21 VAS code from the table ZPWEAVER_VASRL. As a result, the delivery document packed successfully as per other vas codes available P01 & P07. Below is the screen shot after packing.
Ex. NECNED 300:
SO # 74395 (VAS codes- P01, P07, P21)
DEL # 80014480
So We suggested to delete the entry of P21 VAS code from the above table.
02. 04/15/2016: Below is our analysis for the issue which is provided to NE.
A) Any number of same discount types can be used with routine 3; calculation routines 19/20 are optional for assignment in the pricing procedure.
Example-
In the above example, discount of 36.59 (rounded) is offered and the net value of 369.91 is arrived at. Routine 6 assigned on NETP calculate the rounding difference to 0.10- and this is subtracted from Net Price. 906 routine assigned on PNTP calculates this difference and 369.90 is arrived which is divisible by the quantity.
B) Discount types like percentage, quantity, amount, volume can be used with routine 17 . The multiple discounts will not cause any rounding issues. Since multiple discounts are used, calculation routine 19/20 should be used with this routine.
Example-
The discount in this case is calculated by the routine 19 from the net price and based on this the rounding is calculated by the routine 6 assigned on NETP. The Net Price is then set as base price by the calculation routine 17. 906 routine on PNTP resets the Net Price and Net Value.
03. As you know, when we built the Japan "EDI" upload program, the direction received was to use as much of the ROC-style process as possible. Unfortunately, the time-lags in this process (waiting for files to move from SAP to GIS, waiting for the maps to run, waiting for the IDOCs to move from GIS to SAP, and waiting for the IDOCs to be processed in SAP) have become unwieldy. We would like to get a high-level estimate for modifying the process as specified below.
In the current program, an Excel file is processed by ZJEDI, which executes logic, and generates a ROC-style flat file. This is then sent to GIS to generate an IDOC, which is eventually processed by SAP. We would like to instead have the ZJEDI program execute the same logic, but instead of creating a flat file, generate an IDOC directly in SAP, and process the IDOC into a sales order immediately. I believe we've used a similar concept in the past in the old packing program. That program would dynamically generate and process an IDOC.
One thing to keep in mind...if this is feasible, we may expand the use of ZJEDI to other regions. We would want this process to be flexible, so that if region-specific requirements arise, we do not need to create a completely new upload program for the other region.
What is a realistic timeline for you to provide me your thoughts and a high-level effort estimate?
04. I wanted to get your thoughts on this job we run in SAP. I had to create 4 instances of this job because if I put them into one job with 4 steps... then if the first program encounters no file, then the entire job fails and it does not run the rest of the steps.
Is there a way to not have the job cancel?
Can we store the variants in a user maintained table somewhere in SAP? This way we can add / delete variants without re-writing code?
Resolution
01. 04/11/2016: We are waiting for the NE suggestion, if required we may need to remove the entry of VAS code P21 from the table ZPWEAVER_VASRL.
02. 04/15/2016: we'd need to make sure that in either case the pricing routines (other than those on NETP and PNTP) are applied per standard practice to avoid rounding issues.
We suggested thorough testing (current and proposed discounts) with either routines.
03. When the program was developed for Japan, we had proposed generating IDOC directly but it was preferred to be processed by GIS. We could generate the IDOC directly in the program but then we would need to build in parameters to make it dynamic for region specific requirements.
Examples –
- 1. Upload file format
- 2. Fixed and variable values/fields
- 3. Multiple sales orgs
- 4. Contract calls offs or just sales orders
- 5. Same or different PO types for each region
Also, we’d need to understand the business rules – region wise for the program to behave dynamically.
04. If setting up multiple jobs is to be avoided, then in that case we can create a program around the job and add all the variants in it. The program will be coded to check the processing status of each variant and move on.
We could try creating a variable in TVARVC and maintain the required variants, but we'd need to check/test to confirm.
We’ve done a high level test to confirm the job doesn’t break when a blank file is encountered on a variant. We can go ahead with the development, please assign a ReCAP to Damodar.
Release Information
Provide link here to Release Notes if Technical Objects were changed